A mobile terminal is an important component in the entire mobile operation service system. Device management (DM) means that a data packet is downloaded to a terminal device from a network side in an Over The Air (OTA) mode and the terminal device is instructed to perform processing, so as to accomplish subsequent functions such as parameter configuration, software installation, and error diagnosis.
In DM specifications designed via the Open Mobile Alliance DM (OMA DM), protocol support for management of a terminal device is already achieved. FIG. 1 is a schematic view of the overall structure for a DM server to manage a terminal device. A DM client on the terminal device is adapted to explain and execute a management command delivered by the DM server. A DM management tree on the terminal device may be regarded as an interface that the DM server manages the terminal device through a DM protocol. A group of Management Objects (MOs) exist in the management tree. The DM server achieves the objective of managing terminal resources through an operation on a node (a management node) in the MO.
As shown in FIG. 1, in the prior art, the DM management is performed through two steps, namely, bootstrap and subsequent management. The bootstrap occurs before a management session between a server and a terminal device is established for actual management, and is adapted to configure account information (such as user name and password) and other parameters (such as a connection parameter). In the subsequent management process, a management session is established. The server may acquire some basic information (such as firmware version, software version, and large object support) of the terminal through the MO of the terminal device, and use the information as a reference for subsequent management actions.
In the prior art, although the protocol support for the management of the terminal device is already achieved, problems such as management effectiveness, efficiency, and communication traffic still exist. For example, a server may not obtain an address of a terminal DM object and DM capabilities supported by the terminal (such as capabilities of support for software component management and support for firmware upgrade) rapidly and the terminal uses a SmartCard for re-bootstrap, which are specifically as follows.
1. After the terminal is locally re-bootstrapped (for example, after the device is changed), the server does not know that the terminal is bootstrapped, so that the authentication-related information stored in the server might be inconsistent with the authentication-related information after the terminal is bootstrapped, resulting in that identity authentication may not be accomplished for the two parties, so that normal management fails.
2. In order to enable the server to obtain situations about limits of the management tree by the terminal device or the implementation of the management tree by the terminal, in the prior art, a terminal manufacturer describes its device and releases the description for reference by a DM party through the Device Description Framework (DDF). However, in the existing protocol, a server side is unable to find its corresponding DDF through the terminal device, so that it is more difficult for the server to acquire the DDF.
3. The server may not obtain Management Object (MO) types supported by the terminal and also wastes network resources. As the DDF is usually static or is scarcely changed dynamically, it is difficult for the server to obtain all MO types supported by the terminal according to the DDF. The server determines whether the terminal supports a certain DM capability through a result returned by the terminal only after a corresponding management command is delivered, and the delivered management command carries a large amount of data (for example, software component management), so that server and network resources are wasted.
4. In the prior art, the server may not acquire a specific property value of all management nodes in a certain management subtree on a device management tree in batch in a non-serialized mode, and so the properties need to be acquired for several times, resulting in low efficiency.
5. It is very difficult for the server to locate the management node of the terminal and air resources are consumed. In order to acquire the terminal management node, the server might need to interact with the terminal for several times or acquire the entire directory structure of the terminal, so that the air resources are occupied and load on the server is increased.
6. In the prior art, the server may not instruct the terminal to sequentially execute a plurality of elements in a single management command, so that an action that requires sequential execution has to be divided into a plurality of management commands that are executed sequentially for implementation, so the cost for message management and parsing and execution by the terminal is increased.
7. When it takes a long time for the terminal or server to process an action, the session might be interrupted, such that the management action fails to be accomplished. Thus, the management that takes a long time becomes difficult. In addition, when a party confirms that a management command needs to be sent before long, the current session may not be maintained and the current session might be interrupted. The management session must be reestablished when the management command needs to be sent subsequently, causing a large cost.
8. When the terminal has a plurality of MO instances, the server does not know which instance is activated currently, resulting in higher difficulty in server management.